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ABSTRACT 



A method of performing a network management transaction 
between a network device, having a network management 
agent installed thereon, and a remote device, having a 
web-browser installed thereon, is described. The method 
involves firstly performing a network management function 
relating to the network device. Data concerning the network 
management function is then propagated from the agent to 
the remote device in a format capable of display by the 
browser. More specifically, a document is propagated from 
the agent to the remote device for display by the browser, the 
document incorporating the data concerning the network 
management function. "Hie document may be an HTML 
document. Alternatively, the data may be propagated in a 
format for display by the browser under the direction of an 
application program resident of the remote device. 

22 Claims, 17 Drawing Sheets 
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METHOD OF PERFORMING A NETWORK 
MANAGEMENT TRANSACTION USING A 
WEB-CAPABLE AGENT 

This application claims the benefit of U.S. Provisional 5 
Application Sen No. 60/024,803, filed Aug. 29, 1996. 

FIELD OF THE INVENTION 

The present invention pertains to the field of network 
management. More particularly, the present invention 
relates to a protocol for performing network management 
using a web-capable network management agent. 

BACKGROUND OF THE INVENTION 

llie proliferation of both local area networks (LANs) and "^^ 
wide area network (WANs) has resulted in increasing 
demands being made on network management tools and on 
network management personnel. In order to increase the 
ease and speed with which network management personnel 
are able to perform management tasks and respond to 
network problems, it is desirable to provide such personnel 
with convenient and ready access to network management 
tools. 

The Internet, and more specifically the World Wide Web 25 
(hereinafter referred to as "the web") component thereof, 
have become increasingly accepted as a medium of data 
communication in recent years. Programs which allow docu- 
ments and objects to be retrieved fi'om the web, and to be 
viewed are generically termed "web browsers". Hypertext 3Q 
Markup Language (HTML) is the language used for the 
construction of documents that are viewable by web 
browsers, and a specification of this language is provided in 
the Request For Comments (RFC) document by Beraers- 
Lee, T, D. Connolly, "Hypertext Markup Lanugue — 2.0", 35 
RFC 1866, MIT Laboratory of Computer Science, Novem- 
ber 1995. A large number of browsers are commercially 
available, including the Netscape Navigator® browser 
developed by Netscape Communications of Mountain \^ew, 
Calif., and the Microsoft Internet Explorer® browser devel- 
oped by Microsoft Corporation of Redmond, Wash. 

While browsers operate to display HTML documents, 
they are also responsible for negotiating a HyperText Trans- 
port Protocol (HTTP) with a web server prior to the retrieval 
of an HTML document or other object, the submission of 45 
information firom the browser to a web server, and respond- 
ing to requests to "fink" to (or retrieve) other HTML 
documents identified in an HTML document currently dis- 
played by the browser, "llie capabilities of web browsers and 
servers are further continually being enhanced by the devel- 50 
opment of so-called "plug-ins", which are software modules 
which can be added to web browser and server software to 
provide enhanced functionality. 

In view of the popularity and proliferation of the web 
browsers there has been some development towards allow- 55 
ing network managers to perform network management 
functions utilizing a web browser over the internet or an 
intranet. Referring to FIGS. lA and IB, two arrangements 
for facilitating management of a network segment 10, uti- 
lizing a web browser, are illustrated. The network segment 60 
10 comprises a network management station 12 and a 
network device 14, which may be a host, gateway, terminal 
server, hub, repeater, bridge or frame switch. A network 
management application 16 resides on the network manage- 
ment station 12, whUe a network management agent 18 65 
resides on the network device 14. llie application 16 and the 
agent 18 communicate management information using the 
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Simple Network Management Protocol (SNMP), as defined 
in the RFC by Case, J. M. Fendor, M. Schoflfetal, and J. 
Davin, "The Simple Network Management Protocol", RFC 
1157, University of Tennessee at Knoxville, Performance 
Systems International, Performance Systems International, 
and the MIT Laboratory of Computer Science, May 1990, 
More specifically, the agent 18 will provide the application 
16 with status information regarding network activity relat- 
ing to the network device 14, either when polled by the 
application 16, or as a trap. The application 16 assimilates 
network status information from a number of network 
management agents to provide a network manager with an 
overall view of network activity and status. A network 
manager can perform network management functions by 
receiving messages from and sending messages to the agent 
18. 

All network management functions with an SNMP envi- 
ronment are performed by altering and inspecting variables 
or "managed objects". These managed objects are termed 
Management Information Base (MIB) objects, and each 
network management agent 18 supports a predetermined set 
of MIB objects (termed an SNMP MIB view of that agent ). 
The sets of MIB objects supported by various network 
management agents may vary from network device to net- 
work device. A number of MIB objects are defined in the 
RFC by McCloghrie, K., and M. Rose, "Management Infor- 
mation Base for Network Management of TCP/IP-based 
Internets", RFC 1156, Hughes LAN Systems and Perfor- 
mance Systems International, May 1990. Examples of such 
managed objects includes the "sysUpUme" object (which 
provides a value indicating the time since the network 
management portion of a system was last re-initialized) and 
the "ifAdminStatus" object (which indicates whether an 
interface is up, down or in a testing state). 

In order to maintain the simplicity of the SNMP, the 
exchange of messages using the SNMP utilizes an unrehable 
datagram service, such as the User Datagram Protocol 
(UDP) as specified in the RFC by Poster, J., "User Datagram 
Protocol", RFC 768, USC/Information Sciences Institute, 
November 1980. The UDP protocol allows the transmission 
of message packets in a serial fashion, and accordingly has 
a limited bandwidth. 

Also shown is FIG. lA is a remote device 20, such a 
desktop computer, on which is resident a client 22 in the 
form of a web browser. The client 22 communicates with a 
proxy agent 24, which is resident on the network manage- 
ment station 12 using the Hypertext Transfer Protocol 
(HTTP), as defined in the RFC by Fielding, R., H. Frystyk, 
T Beraers-Lee, J, Gettys, J. C, Mogul, "Hypertext Transfer 
Protocol— HTTP/1.1", RFC xxxx, UC Irvine, MIT Labora- 
tory of Computer Science, MIT Laboratory of Computer 
Science, DEC, DEC, April 1996, Accordingly, all data 
packages passed between the client 22 and the proxy engine 
24 conform to the HTTP protocol. The proxy agent 24 
receives and translates data packages from the client 22 into 
a format understood by the network management application 
16, before propagating the translated message to the appli- 
cation 16. Accordingly, the proxy agent 24 is an intermediate 
program which acts as both a server and a client for the 
purposes of translating and forwarding requests to the appli- 
cation 16 on behalf of the client 22. Similarly, messages 
intended for transmission from the application 16 to the 
client 22 must firstly be propagated to the proxy agent 24, 
which translates the message into a format required by the 
HTTP protocol. After performing the translation, the proxy 
agent 24 then propagates the message to the client 22. 

FIG. IB shows the network management station 12 and 
the network device 14 which communicate network man- 
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agemenl information according to the SNMP protocol, as from the browser to the agent. The menu HTML document 

described above. However, the proxy agent 24 is now shown includes static information concerning the network device, 

to reside on the network device 14, instead of the network and includes a number of URIs (or URLs) including embed- 

management station 12. In the shown arrangement, the client ded method tokens for initiating network management func- 
22 installed on the remote device 20 communicates with the 5 tions. 

network management agent 18 via the proxy agent 24 as a network management function may involve the 

described above. In this case, the proxy agent 24 translates retrieval of network management information, the allocation 

a message received from the client 22 from a format of a value of a network management object, or the setting of 

specified by the HTTP protocol to a format specified by the a trap on a network management object. 
SNMP format. Similarly, a message from the network man- lO ^ connection is estabHshed between the agent and the 

agement agent 18 to the chent 22 IS transited ^^^^^^ connection is maintained for multiple 

agent 24 from a format specified by the SNMP protocol to „ #. , ,i „ « . «• u . .u * jfu 

% , , . TTrr^r,^ , network management transactions between the agent and the 

a format specified by the HTTP protocol. ^^^^^^ ^^^.^ 

While the arrangements shown in FIGS. lAand IB allow ^^^^^^^ ^ computer-readable medium 

a degree of network management to be performed from a 15 ^ instructions thereon which, when 

chent 22 resident on a remote device, there are a number of «„^™.T«^ u., ^~>^^^,„, tu « tu^ i ^ • .u 

, . , ' r., . executed by a processor within the network device, cause the 

limitations mherent m these arrangements. Specifically, the L ^ a * a u 

, . M . , i , processor to perform the steps detailed above. 

HTTP protocol is primarily intended to facihtate the , . 

retrieval of static documents by a cUent from a server The invention also extends to a network device having a 

SNMP protocol is intended to facilitate network manage- 20 processor and a memory coupled to the processor, the 

ment in a simple and effective manner. Furthermore, the P^^^^^ ^ mstructions which, when executed 

existence of a proxy agent for the translation of messages the Processor, cause the processor to perform the steps 

between the two protocols is inefficient and undesirable. aetaiiea aoove. 

Other features of the present invention will be apparent 

SUMMARY OF THE INVENTION 25 from the accompanying drawings and from the detailed 

, . * 1 * * 1 description which follows. 

The present invention contemplates a network manage- ^ 

ment protocol wherein a method token, associated with a BRIEF DESCRIPTION OF THE DRAWINGS 
network management function, is incorporated or embedded 

directly into a Uniform Resource Locator (URL) or Uniform The present invention is illustrated by way of example 

Resource Identifier (URI) propagated from a browser. Data and not limitation in the figures of the accompanying 

generated by the performance of the network management drawings, in which like references indicate similar elements 

function is then communicated by a network management in which: 

agent to a browser in a format that can be displayed by the FIGS. lA and IB are schematic representations of 

browser. arrangements for managing a network from a remote device 

According to the invention there is provided a method of having a web-browser installed thereon, 

performing a network management transaction between a FIG. 2 is a schematic representation of a network device 

network device having a network management agent having a network management agent according to the 

installed thereon and a remote device having a browser present invention installed thereon, and connected to remote 

installed thereon. The method involves firstly performing a devices via an internet or an intranet, 

network management function relating to the network FIG. 3 is a schematic representation of a network device 

device. Data concerning the network management frmction ^vtiich the network management agent according to the 

is then propagated from the agent to the remote device in a present invention is installed, and having a storage device 

format capable of display by the browser. More specifically, including a computer-readable medium on which the agent 
a HTML document is composed by the agent and then 45 stored 

propagated from the agent to the remote device for display 4 ^ diagrammatic representation of a Uniform 

by the browser, the document mcoqporating the data con- ^^^^^^ Locator(URL) Dictionary according to the present 

cerning the network management function. Alternatively, invention 

the data may be propagated in a format for display by the ^^r^ ^ 

browser under the direction of an application program ..^'^".^ P^°^',^f a diagrammatic representation of data 

resident of the remote device. maintained by the network management agent accord- 

^ , . . . . . ing to the present invention. 

The network management ni notion relating to the network ^ . . • • r . r . 

device is performed in response to a network management ^j^" ^ \^ schematic representation of a number of the 

request issued from the browser. The network management "^^'^^^^^^ ^^'J^'^^ ^^^^ '^^'''^ ^°^P"^ 

request may be included in a data packet received at the 55 "^^'^^g*^"^^"^ according to the present invention, 

agent, the data packet including a plurality of network ^I^- is a diagrammatic representation of a number of 

management requests. The network management function software modules that are invocable within the network 

addresses a network management object, and performing the management agent of the present invention, 

network management function requires that an object iden- FIG. 8 is a flow chart illustrating a method according to 

tifier included within the network management request be go present invention by which the network management 

associated with the network management object. agent processes a received network management request. 

Prior to a network management request being issued from FIG. 9 is a slate diagram illustrating the stales in which a 

the browser, a list of network management functions sup- request manager software module, comprising part of the 

ported by the agent is sent from the agent to the remote network management agent according to the present 
device. ITie agent may also transmit a menu HTML docu- 65 invention, can reside. 

ment to the remote device for display by the browser, the FIG. lOA shows the software functional layers within a 

menu document providing an option to issue the request network device shown in FIG. IB. 
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FIG. lOB shows the software functional layers within a method token directly into a URL string of a message 

network device according to the present invention, transmitted from a client to the network management agent. 

FIG. 11 is a flow chart illustrating a generic method of Appropriate action is then applied to an identified URL 

performing a network management transaction according to ^^'J^* ^° embedded method token. 

the present invention. 5 A description of the hardware in which the present 

r-T^o a u . 11 . 1 invention may be employed, as well as the structure of the 

HGS. 12-14 are flow charts lUustraling specific examples ^j^^^ ^y^^j, ^^ ^^^ ^ 

of the genenc method shown m FIG. 11. ^e described below. Thereafter, a description of the meth- 
FIGS. 15A-15C are schematic illustrations of the odology employed by the present invention will be pro- 
exchange of request and response messages between a vided. 

browser and a network management agent according to a ^ o * • 

, J i_ .i_ . • 7- 3. System Description 

protocol proposed by the present invention. ^ ^ Network 

FIG. 16 is a diagrammatic representation of a request Referring to FIG. 2, in one embodiment of the present 

message strucmre according to the present invention. invention, an embedded, web-capable network management 

FIG. 17 is a diagrammatic representation of a response 15 agent 30 resides on a network device 32, to which a number 

message structure according to the present invention. of end devices 34 are coupled. The network device 32 may 

be a router, bridge, hub or any other network device on 

DETAILED DESCRIPTION which network management agents commonly reside. The 

A method of performing a network management transac- ^^^^f ^ /^^^ computers, servers, or peripheral 

tion using a web-capable agent is described. In the following ^^""'^^^ be appreciated that the network device 32 

description, for purposes of explanation, numerous specific "^^^ furthermore be coupled to any number of further 

details are set forth in order to provide a thorough under- network devices. . 

standing of the present invention. It will be evident, . ^^^^^ be coupled to an 

however, to one skilled in the art that the present invention ^l!^^^^^ ^^P^^ "^^'^^^ 

may be practiced without these specific details. ^^^f ^ remote device 39 such as a computer, on which 

resides a client 40, in the form of a web browser. Similarly, 

1. Terminology remote devices 42 and 44 each have a client 40 installed 

thereon and are coupled to the internet 38. The clients 40 , 

The terms specified below are used throughout the propagate request messages to the network management 

specification, and are intended to have the import, and 30 agent 30 which, in response to the request messages, propa- 

encompass the concepts, as stated below: gates response messages to the clients 40., In one 

1. ) Uniform Resource Identifier (URI): URFs are data embodiment, these response messages incorporate HTML 
strings intended to identify, via name, location or any documents, and accordingly the network device 32 may be 
other characteristic, a network resource. The term URI viewed by the clients 40 as an HTML server. The network 
is intended to encompass a number of terms common in 35 management agent 30 supports a set of managed objects, 
the art, namely a Uniform Resource Locator (URL), a which in one embodiment are Management Information 
Uniform Resource Name (URN), a world wide web Base(MIB)objects.ThesetofMIB objects supported by the 
address, and an Universal Document Identifier (UDI). agent 30 are specific to the network device 32, and are 

2. ) Resource: Any network data object, variable or ser- termed the MIB view of the agent 30. The managed objects 
yice. 40 (or variables) provide information regarding the network 

'^^ nu^^i- a ^.^^^r^ ..rUi^u ;«t^r -,1;, ^t.KK.w o device, such as, for example, the number of good or bad data 

3. ) Client. A program waicn, inter alia, establishes a r j^j. .. .1. ,j- 

™r.^^t;«« o o^r,,^r f^. iu^ «»™cJc ^f^^^A- . frames received at and transmitted from the network device 

connection with a server tor the purposes or sending or 

receiving data. Requests received from client 40 address the managed 

2. Overview of the Invention objects supported by the agent 30 and, as will be described 

in further detail below, may request network management 

The present invention seeks to address the limitations of information regarding the network device 32 from the agent 

the arrangements presented in FIGS. lA and IB by provid- 30. This information is then propagated to the chent 40 in a 

ing a web-capable program (which may be either a network format which can be displayed on the requesting client 40. 

management application or a network management agent) 50 3.2 The Network Device 

which will support a number of network management piG. 3 shows one possible embodiment of a network 

functions, and will have the capability of propagating infor- device 32 in the form of a computer, llie network device 32 

mation regarding such network management functions in a includes a processor 50 for executing the various sequences 

format that is capable of display on a web browser. of instructions which comprise the web-capable network 

Accordingly, a web-capable network management agent 55 management agent 30. The network device 32 further 

proposed by the present invention will present network includes a main memory 52, in which the sequences of 

management information in the format of a HTML instructions which comprise the agent 30 may at least 

document, or in a format which may be used by an appli- partially reside, as shown in FIG. 3, when the sequences of 

cation which interacts with the browser to produce an instructions are being executed by the processor 50. The 

HTML document representing the relevant network man- device 32 further incorporates a mass storage device 54 

agement information. In one embodiment, such an applica- which in one embodiment comprises a drive which operates 

tion may be a JAVA™ "applet". to read data from, and write data to, a computer readable 

The present invention also proposes a protocol, conve- medium 56 on which the sequences of instructions compris- 

niently termed the Hypertext Network Management Proto- ing the agent 30 may be stored, 

col (HNMP) according to which a web-capable network 65 3.3 llie Web-Capable Network Management Agent 

management agent and a client can exchange data. In one llie web-capable network management 30 comprises a 

embodiment, this is achieved by introducing an embedded number of manager modules, execution modules and data 
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Structures, the data structures being modified and maintained 
by the manager and execution modules. The agent 30 
furthermore comprises an interface, namely a URL dictio- 
nary for interfacing between the various modules and the 
data structures. 5 
3.3.1 The URL Dictionary and Data Structures 

Referring now to FIG. 4, the network management agent 
30 maintains a Uniform Resource Locator Dictionary 
(URLD) 60, which contains an entry 62 for each managed 
object supported by the agent 30. Each entry 62 comprises lO 
a number of fields including an OBJECT NAME field 64, 
and OBJECT IDENTIFIER field 66, a DATATYPE field 68 
and an ENUMERATION TABLE field 70. The OBJECT 
NAME field 64 contains a textual name for the managed 
object, which corresponds to a numeric object identifier 15 
contained in the OBJECT IDENTIFIER field 66, The DATA 
TYPE field 68 indicates whether an instance of the object 
will be an octet string, integer, or enumeration. In the case 
where the data type is indicated as being an enumeration, the 
ENUMERATION TABLE field 70 contains an integer cor- 20 
responding to a status. For example, referring to entry 62.2 
in the URLD 60, the data type is indicated as being an 
ENUMERATION, and the ENUMERAHON TABLE field 
70 indicates a value "1", corresponding to an "up" status. 
Similarly, a value of "2" in field 70 would indicate a "down" 25 
status, whereas a value "3" would indicate a "testing" status. 
The last entry in the dictionary, namely entry 62 .N contains 
zeroes in all fields. 

The URLD 60 provides the main interface between a 
request manager module, and the managed objects and file 30 
system of the agent 30. In one embodiment, the managed 
objects all comprise MIB objects, which may in turn be 
classified as SNMP objects, file objects, counter objects and 
miscellaneous objects. 

FIG. 5 shows the three primary data file types that are 35 
maintained by the web-capable network management agent 
30. These file types comprise transaction control blocks 
(TCB) 72, unit data blocks (UDB) 74, and URL blocks 
(URLB) 76. Referring firstly to the transaction control 
blocks 72, a VCB 72 is created for each ina)ming request 40 
received at the network management agent 30 fi-om a client 
40. Each TCB 72 contains the following fields or attributes: 

1. a unit data block identifier (UDB ID): llie contents of 
this field identify a corresponding entry in the unit data 
block 74. 45 

2. a received input data pointer: The memory references 
to the incoming data from the client 40. 

3. a socket identifier: ITie contents of this field indicate the 
socket in which the incoming request was received. 

4. a URLD Identifier: The identification of one of the 
many URLs in the URL dictionary. In essence, it is the 
address of a specific object in the URL pool. 

5. a Header Record Pointer: The attributes related to the 
client request which are specific to the HTTP protocol. 55 
It allows both the Client and Server dealing in HTIT to 
exchange objects (URLs). 

Response data to be provided by the agent 30 to a client 
may be too large to be written to a contiguous output buffer. 
Accordingly, response data may be divided into a number of 
blocks, each of which comprises a unit data block 74. Each 
unit data block 74 contains the following fields or attributes: 

1. a pointer to a following, consecutive UDB 74. 

2. the relevant response data. 

Each URL instance has an allocated URL Block 76, which 65 
contains attributes relating it to the relevant URL. Each URL 
Block 76 will include the following fields or attributes: 
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1. the URI: This is the string which represents a managed 
object. The URI is the name of the URL object and 
items 2-5 below are the attributes. 

2. an Action Method included within the URL instance: In 
one embodiment, the following methods could be indi- 
cated as being Action Methods: 

(a) ls:list files or directories 

(b) cat<filename>:display a file. 

(c) cr<filename>: create a file in the "/usr" directory. 

(d) rm<filenam6>: remove a file from the "Aisr" direc- 
tory. 

(e) ld<filename>:load a file from browser to the "/usr" 
directory in the server. 

(f) select: select the columns in a table. 

3. Arguments: This is an array of argument records, and 
incorporates an argument name and an argument value. 

4. URL Type: This field indicates the file extension type 
such as, for example, ".moca", ".html", ".gif , or ".txt". 

5. Mode: This indicates the output format of the URL. 

3.3.2 Manager Modules (The HTML Server) 

FIG. 6 illustrates a number of the primary modules and 
objects of the web-capable network management agent 30, 
and also illustrates the interaction between these modules 
and objects. 'ITiree manager modules are shown to comprise 
a so-called "HTML server" 80, these manager modules 
comprising a task manager 82, a request manager 84 and a 
response manager 86. The manager modules which com- 
prise the HTML server 80 manage network management 
functions performed in response to requests received from 
the client 40. 

The task manager 82 is a daemon which is activated on 
system initialization and creates a socket on a dedicated 
HTML port (for example, port 80) and then listens on that 
port for incoming requests propagated to the agent 30 from 
a client 40. Upon receipt of an incoming request, the task 
manager 82 creates a socket, and spawns a request manager 
84, which is dedicated to managing the received request, 
lliis process repeats itself until a predetermined number (for 
example four) of socket and request manager pairings have 
been created. Once the predetermined number of sockets and 
request manager pairings have been created, the task man- 
ager will distribute further incoming requests to queues 
associated with each pairing on a rotating basis. 

As stated above, a dedicated request manager 84 is 
assigned to manage each incoming request received at the 
agent 30 from a client 40. The request manager 84 is central 
to the HTML server 80, and interacts with the response 
manager 86, the URL dictionary 60 and a number of 
execution modules to process the request and initialize a set 
of data files, as shown in FIG. 5, for the request. A detailed 
explanation of the functioning of the request manager 84 
will be provided below. 

The response manager 86 has the task of formatting and 
buffering output data, which is to be propagated from the 
agent 30 to the client 40 as a response to a request. 

3.3.3 Execution Modules 

FIG. 7 shows a grouping of execution modules which are 
called, or initiated, by the request manager 84 to perform 
specific functions in processing of a request. 

1. a Tokenizer module 90: A tokenizer module is a module 
which has the embedded knowledge to separate the 
incoming stream of data into manageable tokens. Based 
on this knowledge the tokenizer module 90 determines 
whether or not the incoming data conforms to the 
negotiated protocol. It is called by the request manager 
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84 which feeds it the data stream. The tokenizer module 
90 breaks down the data stream into tokens and then 
activates appropriate parsers for each of the tokens. 

2. a Command Line (CLI) Parser 92: The CLI parser 92 
is responsible for parsing a request-line of a request 
message received at the agent 30 and for initializing a 
URL block 76 for the request with information, 
described above, pertaining to that request, 

3. a Head Parser 94: This module parses a Request- 
Header of a request message received at the agent 30. 
The head parser module 94 is responsible for initializ- 
ing a transaction control block 72 for a received request 
message. The header of the request message is parsed 
to extract data contained in the following fields: 

1. <HTTP-Version>: the version of HTTP supported by 
the client (browser). 

2. <if-Modified-Since>: the expiration date of the URL 

3. <Allow>: methods applied to the URL 

4. <Content-Length>: the length of the entity body of 
the request message: 

5. <Content-Type>: the URI type (text, html, gif). 

4. Entity Body Parser 96: This module is responsible for 
parsing the entity body of a request message received 
from the client 40, or a response message to be propa- 
gated to the client 40, to locate a Server Side Include 
(SSI). A Server Side Include is a tag within a HTML 
document which indicates to a server, from which an 
HTML document is being propagated, that information 
accessible by the server is to be incorporated into the 
HTML document. SSI tags are understood only on the 
server side, and are especially useful to include the 
result of a certain action taken on the server side (i.e. 
dynamic data) within a static HTML document. 
Accordingly, by using SSI tags, it is possible to create 
an HTML document which interlaces static and 
dynamic data. The following code sets out an illustra- 
tive example of an HTML document incorporating SSI 
tags. In the present invention, a <MOCA> tag (and a 
corresponding </MOCA> tag) identify the SSI portion 
of an HTML document. 
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-continued 



<!DOCTYPE KI ML PUBUeV/IETF//DTD 
HrM17/EN"> 

<HTML> 
<HEAD> 

<'nTLE>Presto Home Pagc</nTLE> 
</HEAD> 

<BODY> 

Welcome to the Presto Home Page. Fasten your surfbelt 
and hop on in for an adventurous tour of my Home and 
neighbor. 
<UL> 

<LI><A HREFo'Vsystcm /presto.htmr'> About Mc</A> 
<LI><A HREF""/systcm/topology.htnil">My 
neighbor </A> 

<LI > <A HREF="/s ystcm/docu ments . htmr*>Uscr ' s 

Guide </A> 

</UL> 

My current Port Status Thble: 
<BR> 

<TABLE BORDER> 

<CAPnON>Presto Port Status Tkble</CAPnON> 
<MOCA code-select> 

<PARAM-"Tablc" value-"s5EnPort'Ihblc"> 

</MOCA> 

</TABLE> 



10 



20 



25 



30 



45 



50 



60 



65 



<P> 

</BODY> 
</HTML> 



EXAMPLE 1 

For example, the entity body parser module 96 recognizes 
the following SSI commands as being valid when included 
between the <MOCA> and </MOCA> tags as identified 
above: 

1. Is: list files or directories. 

2. cat: display files. 

3. cr: create a file in a user directory. 

4. rm: remove a file from a user directory. 

5. Id: load a file from a browser to a user directory in the 
server. 

6. select: select the columns in a table sorted by column 
in ascending or descending order. 

5. a Start URL module 98: this module is called by the 
request manager 84, and once activated, proceeds to 
retrieve a URL name and its type from the URL Block 
36. The module then recognizes the URL type, and 
accesses the resource identified by the URL from an 
appropriate location. For example, if the URL identifies 
a file, the file is accessed via a file read system. If the 
URL is identified as being a MOCA command, then a 
MOCA library is accessed. Alternatively, if the URL 
identifies a managed object, this object is then accessed 
via the URL Dictionary 60. 

There are furthermore a number of callback functions 
within the MOCA library, namely: 

6. Moca Is module 100: this callback function accesses 

the file system, and retrieves file names which are then 
formatted into HTML format in the appropriate Unit 
Data Block 74 for propagation to the client 40. 

7. Moca_ld module 102: this callback function is used to 
load and transfer a remote file to the agent 30. llie 
location of the remote file Is determined by an agent- 
.config file, and the file name in the URL. 

8. Moca_get module 104: this module is used to get the 
value of a certain object (URL) within the URL dic- 
tionary. 

9. Moca_set 105: this module is used to set the value of 
a read and write object within the URL dictionary. 

10. Moca_select 106: this caU back function is used to 
provide formatted output table data. 

3.3.4 Methodology — the HTML server 

The method by which a request received at the HTML 
server 80, comprising the task manager 82, the request 
manager 84 and the response manager 86, is processed will 
now be described with reference to FIGS. 6, 8 and 9, FIG. 
8 is a flow chart indicating the various steps performed by 
the HTML server 80, and FIG. 9 is a state diagram, indi- 
cating the various states in which the request manager 84 
resides during performance of the steps shown in the flow 
chart of FIG, 8. 

Referring firstly to FIG. 8, at step 112 the task manager 82 
creates a socket on a dedicated port, for example port 80, and 
then listens at that port for an incoming request from the 
chent 40. On the receipt of a request, and the establishment 
of a TCP/IP connection for that request, the task manager 
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creates a new socket and a dedicated request manager to The response manager 86 transitions between an idle state 

oversee the processing of the request. (not shown) and an active state (not shown). More 

At step 114, the incoming request is received at the specifically, in the idle state, the response manager 86 waits 

request manager 84 for processing. The request manager is for an incoming request directing that a UDB 74 chain be 

at this time in an idle state 150, and calls the Tokenizer 5 sent over a socket specified in an appropriate Transaction 

Module 90, Command Line Parser 92, the Head Parser 94 control Block 72. The response manager 86 enters the active 

and the Entity Body Parser 96 to parse the request at step 116 g^^le once it received a UDB 74 from the request manager 
of the method 110. At step 118, the data extracted from the 

request is stored in a transaction control block (TCB) 72 and i„ ,1,^ «^t;,,^ ot^t^ tu^ Oic ^ 

\ Tinir 1 1 1 ^TTr»F • J ■ 1 . Id active state or the response manager 00, the entire 

at least one URL block (URLB) 76 associated with the „ . * u fc • * *u 1 * tt A * m 1 

, » , vc 11 *t- J T • T» 10 output buffer is written to the socket, one Unit Data Block 

request. More specifically, the Command Line Parser 92 /tjXt^\ . a A^r^^^ . . 

p7rses a request-line of the request, and initializes (or (^^^) ^ ^1"^% ^ ^^^^ "^^^^^^ ^ ^^""^ the 
creates) a URL block 76 with values for the attributes of ^^^^^^^ ^^^"^ transmission of 
such a block, as discussed above. The Head Parser 94 parses ""^P"' ^^^^ ^ ^^i^"^ ^nce the response manager 86 
the headers of the request and initiaUzes a Transaction informed by the request manager 84 that the last request 
Control Block (TCB) 72 for the request. The Entity Body 15 message has been received, the response manager 86 closes 
Parser 96 then parses the entity data body of the message to down the TCP/IP connection for the request in process, 
search for any Server Side Includes (SSIs), and creates and 3.4 Protocol for Performing a Network Management Trans- 
initializes a further URL Block 76 for each SSI encountered. action Between A Web — ^Enabled Network Management 
At step 120, the request manager 84 enters an active state Agent and A Web Browser (the Hypertext Network Man- 
152, as shown in FIG. 9, and interfaces with the URL 20 agement Protocol) 

Dictionary 60 via an appropriate Application Program Inter- A web-enabled network management agent 30, which is 

face (API) to activate the requested method (now indicated capable of receiving a network management request from a 

in the URL block 76) on a URL object identified in the client 40, in the form of a web browser, and of propagating 

request. More specifically, the request manager 84 interfaces the results of a network management function performed in 

with the URL Dictionary 60 by caUing the Start URL 25 response to such a request in a format capable of display by 

module 98. The URL Dictionary 60 then uses the URL the browser, has been described above. A description of the 

attribute value maintained in the appropriate URL Block 76 protocol by which request messages are propagated from the 

to access the managed objects 88 (as shown in FIG. 6), or the client 40 to the agent 30, and by which response messages 

file system 89. At step 122, assuming the access operation is are propagated from the agent 30 to the chent 40, will now 

successful, the URL Dictionary 60 returns output data to the 39 be described. 

request manager 84, in the form of a series of Unit Data xhe existing HTTP protocol is specifically directed 

Blocks 74. towards performing a method (or operation) on a single 

At step 124, the output data is again parsed by the Entity object identified by a URI, URN or URL. The methods 

Body Parser module 96 to locate any Server Side Includes specified by the HTTP protocol are directed towards the 

within the output. If the Entity Body Parser module 96 35 retrieval of static documents, such as HTML documents, as 

locates a Server Side Include in the output at decision block well as the storing of documents under a specified URL. The 

126, the method proceeds to step 128 wherein the request method of operation on a URL object is specified by the 

manager 84 again interfaces with the URL Dictionary 60 to client. However, the HTTP protocol is particularly unsuited 

activate the method of the Server Side Include on a URL to network management functions for a number of reasons, 

object, lliis iteration proceeds until it is determined at 40 For example, the HTIT protocol does not facilitate the 

decision block 130 that all output data has been parsed. The retrieval or manipulation of multiple URL objects, 

method 110 then proceeds to step 132, where the request Accordingly, complex and clumsy Application Program 

manager 84 enters the sending state 154, as shown in RG. Interfaces (APIs) and Common Gateway Interfaces (CGIs) 

9. The request manager 84 then communicates with the must be written to allow for the management of objects on 

response manager 86 by instructing the response manager 86 45 the server side. 

to flush "ready to send" data to the client 40. On receiving The Hypertext Network Management Protocol (HNMP) 

a successful handshake from the response manager 80, the proposed by the present invention seeks to address the 

request manager 84 retums to the active state 152. On the limitations of the HTTP protocol with respect to network 

other hand, should a transmission or "time out" error occur management functions by introducing an embedded method 

at this stage, the request manager enters a release state 156. 50 token directly into a URL string. The method specified by 

Errors may result from the foUowing: the embedded method token is then applied to a URL object. 

1. the client might close the connection prematurely; or Accordingly, the HNMP protocol provides a greater degree 

2. there may not be any further buffer capacity available of functionality than the HTTP protocol, making the HNMP 
at the transport level to send out any more data. protocol particularly suitable for network management pur- 
Assuming a successful handshake with the response man- 55 poses. 

ager 86, the request manager 84 will transition from the 3.4.1 Functional Software Layers 

active state 152 to the release state 156, and will release all Referring to FIG. lOA there is shown a diagrammatic 

resources associated with the request and return to the idle representation of the software functional layers resident on 

state 150, the network device 14 shown in FIG, IB. The functional 

It may also occur that, at step 122, the output data 60 layers comprise an operating system layer 160, a transport 

received from the URL Dictionary 60 may exceed the layer 162, a protocol layer 164 and an application layer 166. 

capacity of an output buffer, in which case the request The transport layer 162 may include a TCP/IP protocol 168, 

manager 84 enters the sending state 154 and communicates which provides the transport layer for the HTTP protocol 

with the response manager 86 to flush the contents of the 170, and a UDP protocol 172 which provides the transport 

output buffer to a client 40. Once the output buffer has been 65 layer for the SNMP protocol 174. As described above, a 

flushed, the request manager 84 then retums to the active proxy agent 176 translates messages formatted according to 

slate 152. the HTTP protocol to a format specified by the SNMP 
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protocol, and vice versa. An HTML server 178 is able to It will be appreciated that once steps 202, 204 and 206 

communicate with a client, in the form of a web browser, have been completed, the client is able to transmit numerous 

using the HTTP protocol 170, and a network management request messages, either automatically or in response to a 

agent 180 is able to communicate with a network manage- manual input from a user, to the agent 30, requesting various 

ment application via the SNMP protocol 174, 5 network management functions. Thus, for each occasion that 

Referring now to FIG. lOB, there is shown a diagram- steps 202-206 are performed, the method may involve 

matic representation of the software functional layers numerous iterations of steps 208-212. 

installed on a network device which is capable of commu- The agent 30 may also generate an unsolicited "response" 

nicating with a browser using the HNMP protocol, and message for propagation to the client in the event of an alarm 

having a web -capable agent according to the invention lo or alert condition, which requires a network administrator's 

installed thereon. The functional layer structure shown in immediate attention. Such alarm responses may also be 

FIG. lOB differs from that shown in FIG. lOA in that the generated in response to a trap installed on the agent 30. 

protocol layer need not include a proxy agent or the SNMP FIG. 12 shows a specific example of the method 200, in 

protocol. The application layer 166 comprises the web- which the request message propagated at step 208 includes 

capable network management agent 186, and a URL dictio- 15 a GET instruction and identifies one or more MIB objects 

nary 188. The agent 186 is able to communicate with a web extracted from a URL Dictionary 60. In this case, at step 

browser utilizing any of the protocols included in the 210, the network management agent will determine specific 

protocol layer 164, values (or instances) of the MIB objects, and these values, 

3.4.2 Response— Request Exchange paired with the appropriate object identifiers, will be propa- 

Referring now to FIG. 11, there is shown a method by 20 gated back to the client from the agent at step 212. 

which request and response messages are exchanged Certain network management functions may allow data 

between an HTML client, such as a web browser, and a values to be assigned to certain MIB objects. FIG. 13 shows 

web-capable network management agent, functioning as an a further specific embodiment of the method 200, in which 

HTML server. At step 202, the client and the agent enter into the network management function comprises a SET 

a protocol negotiation, and establish the HNMP protocol as 25 instruction, which is propagated within a request message, 

the communication protocol. Contrary to the HTTP protocol together with one or more MIB object identifiers and asso- 

wherein a connection between a client and a server is ciated data values, from the client to the agent at step 208. 

severed once a request or a response message has been At step 210, the agent 30 assigns the data values to the 

transmitted, the agent 30 maintains a TCP/IP connection respective MIB objects, and at step 212 the agent transmits 

between the client and itself until the cfient severs the 30 a response to the client, acknowledging success or failure of 

connection, or the agent itself severs the connection. the set instruction. 

Accordingly, numerous request and response exchanges can FIG. 14 shows yet another specific embodiment of the 

occur without the connection being severed. method 200. At step 210, a request message including a 

At step 204, the client propagates, and the agent 30 TRAP instruction, and listing one or more MIB objects 

receives, a request message requesting that the agent 30 35 extracted from the URL Dictionary 60, is propagated from 

supply a URL Dictionary 60 to the client. As discussed the client to the agent 30. At step 210, the agent 30 creates 

above, the URL Dictionary 60 comprises a list of managed traps on the listed MIB objects. Accordingly, any change in 

objects supported by the agent. At step 206, the agent 30 the value of the MIB objects identified in the request 

propagates a response message to the client, the response message will cause a response message to be transmitted to 

message incorporating the URL Dictionary 60. Accordingly, 40 the client. At step 212, the agent 30 transmits a response 

the client is able to ascertain from the response message message to the client, confirmii^g the creation of the 

which managed objects are supported by the agent 30. The requested traps. 

agent 30 furthermore includes an HTML document in the FIG. 15A-15C provide a representation of the exchange 

body of the response message. This HTML document is of request and response messages between an HNMP client 

displayable by the client to present a user with a menu of 45 and an agent 30, functioning as an HNMP server, 

various network management options that can be exercised. The GET instructions discussed above are particularly 

More specifically, the HTML document contains the hyper- useful in allowing a browser to display an instantaneous 

text links to managed objects supported by the agent 30. The measurement or value of a certain network management 

HTML document may optionally present the network man- function parameter, identified by a MIB object. Furthermore, 

age ment functions in a tabular form. 50 by periodically transmitting GET requests to an agent 30, a 

At step 208, the client propagates a request to the agent client in able to provide a network manager viewing a 

30, the request including an instruction to perform a network browser with a continual update of a monitored parameter or 

management function. The request further identifies one or MIB object. For example, an object identifier may address a 

more managed objects, extracted from the URL Dictionary "GOOD FRAMES" managed object, which maintains a 

60, on which the network management function is to be 55 record of the number of uncorrupted message frames 

performed. In one embodiment, the network management received at a specific network device which the agent is 

function is either a GET, SET or TRAP function. Each monitoring. By continually directing a GET instruction at 

managed object identified within the request message is such a "GOOD FRAMES" managed object, the client is able 

identified by an object identifier, which is extracted from an to provide a network manager with a continual indication of 

OBJECT IDENTIFIER field 66 of a respective entry within 60 the number of uncorrupted frames being received at the 

the URL Dictionary 60, For example, the object identifier network device. Similarly, by setting a trap on, for example, 

"1.3.6.2.1.1.1" would identify the "sysDescr" MIB object. the "GOOD FRAMES" managed object, a user can be 

At step 210, the agent 30 performs the function on the provided with a continual update regarding the number of 

managed objects, according to the object identifier in the uncorrupted frames received at the network device, 

request message from the client. At step 220, the agent 30 65 As mentioned above, a response message from the agent 

propagates an appropriate response message back to the 30 (in response to a request incorporating a GET instruction) 

client. incorporates at least one object identifier and a data value 
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assigned to that object identifier. The data value may be message. Furthermore, the protocol proposed by the present 
incorporated in an HTML document for display as a numeric invention allows a continuous and dedicated TCP/IP con- 
value. Alternatively, the data value may be utilized by a nection to be established between a client and a network 
JAVA*^" applet residing on the network device, which inter- management agent 19, thus allowing a network manager, 
acts with the agent 30, to provide a graphic display of a 5 utilizing a browser, continually to monitor various aspects of 
monitored network parameter. » network device. As the HNMP protocol furthermore 
FIGS. 15A-15C provide a diagrammatic representation of "^i^i^^s the TCP/IP transport protocol, it is more robust and 
the exchange of requests and response messages for each of '^^^^^^ ^h^" ^he SNMP protocol, which uses the UDP 
the specific embodiments of the method 200 shown in FIGS. transport layer protocol. ^ , 
12-14. The term "varList" is shown to be incorporated in a lo . °f management agent 30 of the present mven- 
number of the response and request messages, and refers to ^ furthermore advantageous m that it communicates 
a variable list incorporating at least one object identifier, ^^^^ a client in a language understood by the chent (for 
which may or may not have a data value associated there- ^^^"^P^^ ^IML) and accordingly obviates the need for a 
^•jj^ proxy agent. The network management agent 30 allows a 

3.4.3 Request and Response Message Format is ^1^^"^^^ ^1^^^^*^ fu'^u^^ '"^'^ "^''^'^'^ 

HG. 16 provides a diagrammatic representation of the functions provided by the agent, 

structure of a request message 220, which is propagated ^^^^ ^ ^^^.'^^^ performing a network management 

from the client to the agent 30. The request message 220 transaction usmg a web-capable agent has been described 

comprises three primary portions, namely a request line 222, ^^oug^ the present invention has been descnbed with 

a header 224 and an entity body 226. The request fine 222 20 '^^^^^<=l to specific exemplary embodmients, it will be 

includes an embedded method token 222.1. The request line ^^^t"' ^^^^ uT"^ modifications and changes may be made 

222 is particularly significant in that the method token 222.1 .^^ese embodiments without departmg from the broader 

is embedded therein, and specifies an action (or method) to «P^"^ and scope of the mvention. Accordmgly, the specifi- 

be applied to a managed object identified within the request ^^^^^^ j^"^ ^'^^^"8^. '^^^^^^ illustrative 

message 220. Furthermore, the request line 222 may include 25 ^^^^l ] restrictive sense, 

multiple method tokens. For example, embedded method 7 claimed is: 

tokens could specify GET, SET or TRAP functions, as 1- A method of performing a network management trans- 
described above, to be performed on the managed objects ^^^^^^^ a network device havmg a network manage- 
listed within the request message. [^^^^ ^^^."^ '""^'^^^ ^/^^'^^^^ ^ 

The header 224 contains further information fields, 30 "'^^^^^ comprismg: 

including a message identifier field 224.1 which lists the propagating a functions list of network management func- 

network management functions or methods known to the tions supported by the network management agent from 

agent 30. In one embodiment, these would include the GET, the network management agent to the remote device; 

SET and TRAP methods. This list of network management receiving a network management request at the network 

functions is established during the protocol negotiation 35 management agent from the remote device, the network 

phase between the client and the agent 30. management request specifying only network manage- 

The entity body 226 incorporates a variable list field 226.1 ment functions included within the functions fist; 

which may accommodate a list of object identifiers and performing a specific network management function, 

respective values associated with each of these object iden- specified within the network management request, 

tifiers. A request message sent from a client to an agent 30 40 relating to the network device; and 

to request the URL Dictionary 60 will contain no values in propagating data concerning the specific network man- 

the variable list. A request message incorporating a GET agement function from the network management agent 

method token in the request line 222 will merely contain to the remote device in a format capable of display by 

object identifiers, which will have no values associated the browser. 

therewith. A request message incorporating a SET 45 2. The method of claim 1 wherein the propagating com- 

instruction, as illustrated in FIG. 15B, will include at least prises propagating a document from the network manage - 

one object identifier and a value associated therewith. ment agent to the remote device for display by the browser. 

Referring now to FIG. 17, there is shown a diagrammatic the document incorporating the data concerning the specific 

representation of a response message 230. The response network management function. 

message 230 includes a status line 232, a header 234 and an so 3. The method of claim 2 wherein the document is an 

entity body 236, As shown, the header 234 may include both HTML document. 

a message identifier and an error identifier, l^e entity body 4. The method of claim 1 wherein the propagating com- 

236 includes a variable list field 236.1, as detailed above. In prises propagating the data in a format for display by the 

a response message sent from an agent 30 in response to a browser under the direction of an application program 

request message incorporating a GET method token, the 55 resident of the remote device. 

variable list field 236.1 will incorporate at least one object 5. The method of claim 1 wherein the specific network 

identifier and an associated value. management function is performed in response to a network 

In conclusion, the protocol for performing a network management request issued from the browser, 

management transaction and the web-capable network man- 6. The method of claim 5 including receiving a data 

agement agent of the present invention are particularly 60 packet at the network management agent, the data packet 

advantageous in that they provide a mechanism whereby including a plurality of network management requests, 

network management can be performed over an internet or 7. The method of claim 1 wherein the specific network 

an intranet using a web browser. The protocol proposed by management function addresses a network management 

the present invention is advantageous in that it addresses the object, and wherein the performance of the specific network 

inadequacies of the HITP protocol with respect facilitating 65 management function includes associating an object identi- 

network management by allowing the retrieval and manipu- fier included within the network management request with 

lation of multiple managed objects utilizing a single request the network management object. 
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8. The method of claim 1 including propagating a menu 
document from the network management agent to the 
remote device for display by the browser, the menu docu- 
ment providing an option to issue a network management 
request from the browser to the network management agent. 

9. The method of claim 8 wherein the menu document 
includes static information concerning the network device. 

10. The method of claim 1 wherein the specific network 
management function is the retrieval of network manage- 
ment information. 

11. The method of claim 1 wherein the specific network 
management function is the allocation of a value to a 
network management object. 

12. The method of claim 1 wherein the specific network 
management function is the setting of a trap on a network 
management object. 

13. The method of claim 1 including estabhshing a 
connection between the network management agent and the 
browser, and maintaining the connection for multiple net- 
work management transactions between the network man- 
agement agent and the remote device. 

14. A computer-readable medium having stored thereon a 
plurality of instructions which, when executed by a proces- 
sor of a network device, cause the processor to perform the 
steps of: 

propagating a functions list of network management 
functions, supported by a network management agent 
resident on the network device, from the network 
device to a remote device; 

performing a specific network management function 
relating to the network device, the specific network 
management function being specified within a network 
management request received from the remote device 
and the network management request specifying only 
network management functions included within the 
functions list; and 

propagating data concerning the specific network man- 
agement function from the network device to a remote 
device in a format capable of display by a browser 
resident on the remote device. 

15. The computer-readable medium of claim 14 having 
stored thereon instructions which cause the processor to 
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perform the step of propagating a document from the 
network management agent to the remote device for display 
by the browser, the document incorporating the data con- 
cerning the specific network management function. 

16. The computer-readable medium of claim 14 having 
stored thereon instructions which cause the processor to 
perform the step of propagating the data in a format for 
display by the browser under the direction of an application 
program resident of the remote device. 

17. The computer-readable medium of claim 14 having 
stored thereon instructions which cause the processor to 
perform the step of propagating a menu document from the 
network device to the remote device for display by the 
browser, the menu document providing an option to issue a 
network management request from the browser to the net- 
work device. 

18. The computer-readable medium of claim 14 having 
stored thereon instructions which cause the processor to 
perform the specific network management function of 
retrieving network management information. 

19. The computer-readable medium of claim 14 having 
stored thereon instructions which cause the processor to 
perform the specific network management function of allo- 
cating a value to a network management object. 

20. The computer-readable medium of claim 14 having 
stored thereon instructions which cause the processor to 
perform the specific network management function of set- 
ting a trap on a network management object. 

21. The computer-readable medium of claim 14 having 
stored thereon instructions which cause the processor to 
perform the step of establishing a connection between the 
network device and the remote device, and maintaining the 
connection for multiple network management transactions 
between the network device and the remote device. 

22. The computer-readable medium of claim 14 wherein 
the specific network management function addresses a net- 
work management object, the computer-readable medium 
having stored thereon instructions which cause the processor 
to perform the step of associating an object identifier 
included within a management request received at the net- 
work device with the network management object. 
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